(1) Field of the Invention
This invention relates to mobile wireless communications and, more particularly, to a collaborative multicast routing (CMR) for multicasting in a hybrid, multi-tiered, heterogeneous mobile wireless network.
(2) Description of Related Art
The prior art Dynamic Source Routing (DSR) and Multicast Ad-hoc On-demand Distance Vector Protocol (MAODV) are two exemplary protocols used in a multicast environment. The multicast protocols for wireless networks fundamentally consist of route discovery and route maintenance phases. The prior art Dynamic Source Routing (DSR) protocol is not a multicasting protocol per se, but is a unicast routing protocol designed for bi-directional links that allows nodes to dynamically discover a source route across the network. DSR uses source-directed routing to specify which intermediate node is to be part of the route and establishes paths by recording all the nodes along a critical path. Each data packet sent carries in its header the complete, ordered list of nodes through which the packet must travel. In order to support unidirectional links, a receiver node in a DSR protocol forwards another route request piggybacked to its route reply in response to the received route request. Therefore, it takes one and a half round trips to establish a route using the DSR protocol.
The prior art Multicast Ad-hoc On-demand Distance Vector Protocol (MAODV) is a true multicast protocol, but designed for multicast routing in bi-directional mobile wireless networks. MAODV is a group-leader rooted, tree-based, on-demand routing protocol, which uses soft-state mechanism in a routing table. The route discovery phase of this protocol commences by a group leader broadcasting out a route request control packet (RREQ) across the entire network using an expanding ring search technique. When a node determines that it has a route current enough to respond to the RREQ or be a member itself, the node creates a route reply control packet (RREP) and unicasts the RREP toward the source, using the node from which it received the RREQ as the next hop. After receiving RREPs, the group-leader node selects the route it wishes to use as its link to the multicast tree. This is accomplished by the group-leader node unicasting a Multicast Activation (MACT) packet out to the selected next hop(s) (or nodes), effectively activating the route. When a selected next hop (node) receives a MACT from the group-leader that has selected it as the next hop, this next node unicasts its own MACT to the node(s) it has chosen as its next hop(s), and so on up the multicast tree, until a node which was already a part of the multicast tree is reached. Every node constructs and maintains its own multicast routing table, which contains both its neighbor nodes and its multicast neighbor nodes, generating a large overhead of stored data.
The route maintenance phase of MAODV uses Group Hello (GRPH) message under normal circumstances to maintain a route and RREQ-RREP message for repairing a broken link. To maintain a route under normal circumstances, the group-leader forwards a GRPH message to all nodes within its multicast group. This enables all nodes within the group to maintain consistent and up-to-date information about the group-leader and the multicast group route. To maintain route under circumstances such as a detection of a broken link between two nodes on a multicast route, the node downstream of the break becomes responsible for initiating the repair of the broken link. Of course, it is possible that after a link breaks, the multicast tree cannot be repaired due to a network partition. The group leader node can start up a new multicast tree in a network partition. In order to connect the two parts of the partitioned network as they roam into each other, the group leader of one of the partitions with a lower Internet Protocol (IP) address, upon receiving another partition's packets, initiates the multicast tree repair by unicasting a RREQ to the group leader of the other network partition, where the RREQ-PREP process starts again. It should be noted that only a group leader itself must receive packets from another partition to commence a merging process of the partitioned network.
In light of the current state of the art and the drawbacks to current systems mentioned above, as well as the explosive growth of the Internet and the mobile wireless devices, a need exists for a system and a method that would allow transmission of only a single data stream with few or no replications, that would have small overhead when tracking a path for construction and maintenance of a multicast tree route, and that would work on a hybrid, multi-tiered network with heterogeneous set of nodes. In addition, in order to merge two partitioned multicast groups, a need exists for a system that would not require the group-leader node to come into contact with a node from another partition to commence a merge process and furthermore, the system would not use expanding ring search for the route discovery phase, which in terms of resources is very costly.